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Abstract 


This  document  is  the  final  report  for  Human  Factors  Research  Task  2006-11 1  -  AIMS 
Feature  Development  which  consisted  of  software  development  for  a  research  platform 
desigined  to  simulate  the  operator-machine  interface  and  controls  for  an  airborne  multi¬ 
sensor  surveillance  system.  The  research  platform  is  used  to  evaluate  design  concepts 
and  operator  performance  issues  and  is  modelled  on  the  Advanced  Integrated  Multi¬ 
sensor  Surveillance  (AIMS)  system  (formerly  known  as  the  Enhanced  Low-Light  Level 
Visible  and  Infrared  Surveillance  System  -  ELVISS)  which  is  being  developed  at 
DRDC  Valcartier.  With  up  to  five  sensors,  the  AIMS  will  enhance  the  capability  of 
search  and  rescue  (SAR)  by  allowing  crews  to  operate  effectively  at  night  and  in 
degraded  weather  conditions.  The  report  summarizes  the  work  performed  in  the  project 
and  makes  recommendations  for  the  next  phase.  Core  tasks  included  adding 
functionality  to  over-ride  the  default  sensor  controller  on  the  control  box  and  replace  it 
with  a  universal  serial  bus  (USB)  controller,  and  adding  the  capability  to  rearrange  the 
sensor  windows  and  other  features  on  the  interface  display  and  other  areas  on  the 
interface.  Both  capabilities  were  added  for  the  purpose  of  evaluating  tools  and  interface 
design  concepts. 


Resume 

Le  present  document  est  le  rapport  final  sur  la  tache  de  recherche  sur  les  facteurs 
humains  2006- 1 1 1  -  Developpement  des  caracteristiques  du  systeme  perfectionne  de 
surveillance  multi-capteurs  integre  (AIMS)  -  qui  consistait  a  elaborer  le  logiciel  pour 
une  plate-forme  de  recherche  conguc  pour  simuler  l’interface  operateur-machine  et  les 
commandes  d’un  systeme  de  surveillance  multi-capteurs  aeroporte.  La  plate-forme  de 
recherche  sert  a  evaluer  les  principes  de  conception  et  le  rendement  de  l’operateur  et  est 
derivee  du  systeme  AIMS  (anciennement  appele  Systeme  perfectionne  de  surveillance  a 
intensification  de  lumiere  visible  et  a  infrarouge  ou  ELVISS)  qui  est  en  cours  de 
developpement  a  RDDC  Valcartier.  Equipe  de  deux  a  cinq  capteurs,  le  systeme  AIMS 
ameliorera  la  capacite  de  recherche  et  sauvetage  (SAR)  en  permettant  aux  equipages  de 
travailler  avec  efficacite  la  nuit  et  par  intemperie.  Le  rapport  resume  le  travail  effectue 
dans  le  cadre  du  projet  et  fait  des  recommandations  pour  la  prochaine  phase.  Les  taches 
de  base  comprenaient  l’ajout  de  fonctions  pour  surpasser  le  controleur  des  capteurs  par 
defaut  sur  le  boitier  de  commande  et  le  remplacer  par  un  controleur  a  bus  serie  universel 
(USB)  et  l’ajout  de  la  capacite  a  reamenager  les  fenetres  de  capteur  et  d’autres 
caracteristiques  sur  l’affichage  d’interface  et  d’autres  zones  de  l’interface.  Les  deux 
capacites  ont  ete  ajoutees  dans  le  but  d’evaluer  des  outils  et  les  principes  de  conception 
de  Tinterface. 
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Executive  summary 
Introduction 

To  enhance  the  capability  of  airborne  search  and  rescue  (SAR)  and  general  surveillance 
a  multi-sensor  electro-optical  imaging  system,  the  AIMS  (Advanced  Integrated  Multi¬ 
sensor  Surveillance)  system  is  being  developed  by  Defence  Research  &  Development 
Canada  (DRDC). 

The  system  consists  of  several  sensors  including  electro-optical  (EO)  sensors,  an  Active- 
Gated  TV  (AGTV),  and  Forward-Looking  Infra-Red  (FLIR).  When  combined  in  one 
system  the  suite  will  effectively  extend  the  capability  of  search  and  rescue  and 
surveillance  patrol  missions  beyond  the  limitations  of  conventional  daylight  operation. 
Sensors  are  slaved  together  and  view  the  same  scene  and  are  operated  from  the  cockpit 
of  an  airplane  using  a  joystick  and  controls. 

To  ensure  optimal  performance  the  AIMS  system  requires  an  appropriate  interface  and 
controls,  the  design  of  which  must  realize  the  interaction  between  technological 
capability  and  operator  performance.  A  research  platform  has  been  developed  to  provide 
a  means  for  studying  operator  issues  using  the  system.  This  report  documents  software 
modifications  that  have  been  implemented  to  upgrade  the  research  platform. 

Results 

The  main  deliverables  from  this  tasking  are  updated  software  executable,  source  code, 
and  associated  system  and  user  manuals  for  the  AIMSsim  software,  and  this  report. 

Work  related  to  the  Scenario  Generation  Environment  (SGE)  and  simulation 
management  were  combined  in  one  open-ended,  more  generalized  activity  of  defining 
and  prototyping  a  next  generation  of  the  SGE  that  would  integrate  the  AIMSsim  and  a 
Graphical  User  Interface  (GUI)  -based  scenario  manipulation  environment  called  the 
AIMS  Simulation  Experimentation  Station  (ASES). 

The  “world  hierarchy”  feature  was  replaced  by  a  temporary  change  in  the  terrain 
clamping  of  targets,  based  on  discussions  with  client.  A  future  phase  may  look  at  a  better 
solution  to  the  issue,  but  the  temporary  measure  should  be  sufficient  in  the  medium  term. 

The  following  capability  was  added: 

The  capability  to  support  USB  joysticks  to  override  only  part  of  the  FlyPanel  control 
box; 

•  Configurability  of  the  GUI  via  text  dialog  screens  and  sensor  display  layout; 

•  Configurable  thumbnail  selection  bar; 

•  Several  new  types  of  sensors; 

•  A  high-level  specification  of  ASES. 


Due  to  time  constraints  the  open-ended  ASES  prototyping  and  lower-priority  items  such 
as  “setup  development  environment”  were  not  implemented  as  fully  as  originally  desired 
but  brought  to  a  satisfactory  conclusion  nonetheless. 
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Significance 

The  continued  development  and  upgrade  of  the  AIMSsim  research  platform  provides  the 
AIMS  experimental  team  with  an  appropriate  level  of  simulation  detail  to  conduct 
human  performance  analyses  which  in  turn  delivers  up-to-date  knowledge  and  advice  on 
the  design  of  sensor  surveillance  systems  to  the  military  stakeholder. 

Future  Plans 

Recommendations  for  the  next  phase  include  implementing  a  visualization  of  the  sensor 
path’s  history  on  the  moving  map  display,  providing  a  debug  tool,  upgrading  the 
scripting  language,  and  facilitating  the  copying  and  use  of  old  scripts. 


Schoenbom  O.,  2007;  AIMSsim  Feature  Development  II.  DRDC  Atlantic  CR  2007-302. 
Defence  R&D  Canada  -  Atlantic. 
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Sommaire 


Introduction 

Pour  ameliorer  la  capacite  de  recherche  et  sauvetage  (SAR)  par  aeronef  et  la  surveillance 
generate,  un  systeme  d’imagerie  multi-capteurs  electro-optique,  le  systeme  AIMS 
(systeme  perfectionne  de  surveillance  multi-capteurs  integre),  est  en  cours  de 
developpement  a  Recherche  et  developpement  pour  la  defense  Canada  (RDDC). 

Le  systeme  comprend  plusieurs  capteurs,  y  compris  des  capteurs  electro-optiques,  un 
capteur  de  television  commandee  par  portes  actives  (AGTV)  et  une  camera  infrarouge  a 
balayage  frontal  (FLIR).  L’ensemble  de  ce  systeme  augmente  la  capacite  de  recherche  et 
sauvetage  et  des  missions  de  surveillance  au-dela  des  limitations  des  operations 
classiques  sous  la  lumiere  du  jour.  Les  capteurs  sont  asservis  les  uns  aux  autres  et 
observent  une  meme  scene;  ils  sont  commandes  a  partir  du  poste  de  pilotage  d’un  avion 
au  moyen  d’une  manette  et  d’autres  commandes. 

Pour  assurer  des  performances  optimales,  le  systeme  AIMS  exige  une  interface  et  des 
commandes  appropriees,  dont  la  conception  doit  realiser  1’ interaction  entre  la  capacite 
techno logique  et  le  rendement  de  l’operateur.  On  a  developpe  une  plate-forme  de 
recherche  qui  permet  d’etudier  les  questions  liees  a  l’operateur  du  systeme.  Le  present 
rapport  decrit  les  modifications  logicielles  qui  ont  ete  mises  en  oeuvre  pour  mettre  a 
niveau  la  plate-forme  de  recherche. 

Resultats 

Les  principaux  produits  a  livrer  de  cette  attribution  de  taches  sont  un  logiciel  mis  a  jour, 
un  code  source  executable,  les  manuels  de  systeme  et  de  l’utilisateur  connexes  pour  le 
logiciel  AIMSsim  et  le  present  report. 

Le  travail  en  rapport  avec  l’environnement  de  generation  de  scenario  (SGE)  et  la  gestion 
de  la  simulation  ont  ete  combines  en  une  seule  activite  evolutive  plus  generalisee  de 
definition  et  de  prototypage  d’une  prochaine  generation  de  SGE  qui  integrerait  le  logiciel 
AIMSsim  et  un  environnement  de  manipulation  de  scenario  base  sur  interface  graphique 
et  appele  poste  d’experimentation  de  simulation  AIMS  (ASES). 

La  caracteristique  de  l’«  hierarchie  des  mondes  »  a  ete  remplacee  par  un  changement 
temporaire  du  verrouillage  des  cibles  au  terrain,  en  fonction  de  discussions  avec  le  client. 
Une  phase  future  peut  consister  a  etudier  une  meilleure  solution  du  probleme,  mais  la 
mesure  temporaire  devrait  suffire  a  moyen  terme. 

On  a  ajoute  les  capacites  suivantes  : 

•  Prise  en  charge  des  manettes  USB  pour  surpasser  une  partie  seulement  du 
boitier  de  commande  FlyPanel; 

•  Configurabilite  de  l’interface  graphique  au  moyen  d’ecrans  de  dialogue  et  de 
la  presentation  de  l’affichage  des  capteurs; 

•  Barre  configurable  de  selection  de  vignettes; 

•  Plusieurs  nouveaux  types  de  capteurs; 
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Specification  de  haut  niveau  du  poste  ASES. 


A  cause  des  delais,  le  prototypage  evolutif  du  poste  ASES  et  des  articles  de  priorite 
inferieure  tels  que  l’environnement  de  developpement  de  montage  n’ont  pas  ete  mis  en 
oeuvre  dans  la  mesure  souhaitee  a  l’origine,  mais  ont  quand  meme  ete  menes  a  une 
conclusion  satisfaisante. 

Portee 

Le  developpement  et  la  mise  a  niveau  continus  de  la  plate-forme  de  recherche  AIMSsim 
fournit  a  l’equipe  de  F  experience  AIMS  un  niveau  de  simulation  assez  detaille  pour 
mener  des  analyses  du  rendement  humain,  qui  fournissent  a  leur  tour  a  l’intervenant 
militaire  des  connaissances  a  jour  et  des  conseils  au  sujet  de  la  conception  de  systemes 
de  surveillance  a  capteurs. 

Recherches  futures 

Les  recommandations  pour  la  prochaine  phase  comprennent  la  mise  en  oeuvre  d’une 
visualisation  de  l’historique  du  deplacement  des  capteurs  sur  l’affichage  cartographique 
defilant,  la  foumiture  d’un  outil  de  debogage,  la  mise  a  niveau  du  langage  de  script  et  la 
facilitation  de  la  copie  et  de  l’utilisation  d’anciens  scripts. 


Schoenbom  O.,  2007;  AIMSsim  Feature  Development  II.  DRDC  Atlantic  CR  2007-302. 
Defence  R&D  Canada  -  Atlantic. 
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1.  Introduction 


1.1  Background 

To  enhance  the  capability  of  airborne  search  and  rescue  (SAR)  and  general  surveillance 
a  multi-sensor  electro-optical  imaging  system,  the  AIMS  (Advanced  Integrated  Multi¬ 
sensor  Surveillance)  system  is  being  developed  by  Defence  Research  &  Development 
Canada  (DRDC). 

The  system  consists  of  several  sensors  including  electro-optical  (EO)  sensors,  an  Active- 
Gated  TV  (AGTV),  and  Forward-Looking  Infra-Red  (FLIR).  When  combined  in  one 
system  the  suite  will  effectively  extend  the  capability  of  search  and  rescue  and 
surveillance  patrol  missions  beyond  the  limitations  of  conventional  daylight  operation. 
Sensors  are  slaved  together  and  view  the  same  scene  and  are  operated  from  the  cockpit 
of  an  airplane  using  a  joystick  and  controls. 

To  ensure  optimal  performance  the  AIMS  system  requires  an  appropriate  interface  and 
controls,  the  design  of  which  must  realize  the  interaction  between  technological 
capability  and  operator  performance.  A  research  platform  has  been  developed  to  provide 
a  means  for  studying  operator  issues  using  the  system.  Software  modifications  have  been 
implemented  to  upgrade  the  research  platform. 

1.2  Task  Objective 

The  objective  of  this  Call-Up  was  to  develop  and  improve  the  features  of  the  AIMS 
simulation  software. 

The  main  deliverables  from  this  tasking  are  the  updated  software  executable,  source 
code,  and  associated  system  and  user  manuals  for  the  AIMSsim  software,  and  this  report, 
which  summarizes  the  work  done  in  this  project. 

1.3  This  Document 

This  document  is  the  final  report  for  HFR  Task  2006-111:  AIMSsim  Feature 
Development  II.  Section  2  of  this  document  gives  details  on  the  deliverables  of  this 
project,  section  3  summarizes  the  work  performed,  and  section  4  concludes  by  making 
some  recommendations  for  the  next  phase  of  work. 
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2.  Deliverables 

The  deliverables  for  this  project  consist  of 

•  Updated  AIMSsim  application  package:  zipped  file  containing  executables, 
experiments,  and  supporting  DLL’s,  data  (geometry,  textures,  shader  files,  etc), 
documentation,  and  experiments 

•  Updated  source  code  of  AIMS  HMI  prototype  (packaged  Subversion  database  file) 

•  Updated  User  and  System  manuals  (Microsoft  Word  and  PDF  formats) 

•  Final  report  (this  document),  outlining  any  functionality  that  was  affected  and  any 
future  requirements 

These  have  been  saved  onto  a  CD,  and  sent  along  with  a  hardcopy  of  this  document. 
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3.  Summary  of  Work  Performed 

Work  for  this  project  commenced  January  15,  2007,  and  was  originally  scheduled  to  end 
in  May  2007.  The  SOW  was  amended  in  May  to  set  the  target  end  date  to  August  3 1st, 
2007,  without  any  change  to  the  budget,  thus  spreading  the  work  to  be  performed  over 
more  months  so  as  to  overlap  with  summer  staff.  The  actual  end  date  was  September  30, 
2007. 

Each  work  task  identified  in  the  SOW  is  described  below.  More  details  can  be  found  in 
the  User  and  System  manuals. 

1 .  Multiple  USB  joysticks:  This  consisted  in  adding  the  ability  for  the  experimenter 
to  override  the  FlyPanel’s  joystick  control  (including  its  two  triggers  and  POV  hat) 
with  a  USB  joystick  connected  to  the  PC. 

The  support  for  USB  joystick  override  was  tested  only  with  a  popular  model  of  a 
Logitech  3D  Extreme  joystick,  but  should  carry  over  to  a  large  spectrum  of  USB 
joysticks  thanks  to  the  use  of  the  advanced  Directlnput  API  provided  by  Microsoft. 
Support  for  other  joysticks  should  be  straightforward,  involving  one  of  1)  no  extra 
work,  works  “out  of  the  box”;  2)  reconfiguring  the  USB  joystick  to  match  the 
functionality  expected  by  the  system,  via  the  vendor’s  software;  3)  improving  the 
AIMSsim  software  (specifically,  simlnputs)  to  better  support  new  joystick  models 
incompatible  with  current  mainstream  joysticks. 

2.  Fillet  problem:  This  consisted  in  fixing  a  minor  problem  with  the  path  following 
algorithm,  which  caused  incorrect  aircraft  or  target  motion  in  the  joining  segment 
of  two  path  plans  (path  following  is  discussed  in  section  4.2.10  -  4.2.12  of  the 
User  Manual).  The  identification  of  the  cause  of  the  issue  was  more  work  than  the 
solution.  Fixing  this  problem  allowed  the  removal  of  a  temporary  hack  introduced 
at  the  end  of  the  last  phase  during  the  experiment  development  in  which  random 
circular  paths  were  being  generated  and  strung  together.  Along  with  the  solution  to 
the  problem,  the  fillet  radius  adapts  to  path  joins  more  effectively. 

3.  Acceleration  rate:  This  consisted  in  adding  the  ability  for  the  experimenter  to 
specify  the  acceleration  rate  on  a  path  plan  segment,  rather  than  having  it 
hardcoded.  Moreover,  the  rate  is  a  true  acceleration  rate  (i.e.  speed  per  unit  time) 
rather  than  per  time  step. 

4.  World  hierarchy:  The  objective  of  this  work  item  was  to  identify  the  source  of  a 
problem  noticed  by  the  client  in  the  visual  system  but  not  reproducible  at  CAE  PS 
due  to  the  challenging  nature  of  the  problem,  which  made  it  difficult  for  the  client 
to  capture  and  demonstrate.  Many  exchanges  with  the  client  helped  determine  that 
the  visuals  were  fine  but  that  they  had  conflicting  requirements  not  yet  fully 
understood. 

As  a  temporary  measure,  the  ground  clamping  was  improved  to  make  it 
configurable  via  the  experiment  scripts  by  allowing  the  experiment  to  choose 
between  highest  and  lowest  clamping.  Search  scenarios,  where  an  operator 
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searches  for  a  target  of  interest  in  the  ground  terrain,  can  use  lowest  clamping, 
which  will  cause  the  targets  to  be  under  the  tree  canopy.  This  feature  allows  for 
more  true  to  life  scenarios  where  targets  might  be  camouflaged  and  hidden  by  the 
terrain.  In  target  tracking  scenarios  a  target  is  tracked  with  the  sensor  and  a  tree 
canopy  might  be  less  desirable.  In  this  case  highest  clamping  can  be  used  which 
will  position  the  targets  on  top  of  the  tree  cover. 

The  main  disadvantage  of  this  temporary  solution  is  that  target  tracking  scenarios 
produce  unrealistic  behaviour  when  a  target  is  moving  on  terrain  and  crosses 
roads,  which  in  the  current  database  do  not  have  tree  cover,  thereby  causing  the 
target  to  move  down  and  up  as  they  are  crossing  the  road. 

The  lull  solution  would  involve  separating  the  tree  cover  in  the  terrain  database 
from  the  actual  terrain,  and  adding  the  ability  for  the  system  to  attach  geometry 
(such  as  the  canopy)  to  the  terrain.  This  would  allow  the  experiment  to  select  a 
bare  terrain  (no  tree  canopy)  for  target  tracking  experiments,  and  terrain+canopy 
for  search  experiments,  both  using  lowest-ground  clamping. 

The  client  decided  that  the  temporary  solution  would  be  adequate  until  the  next 
phase  of  work,  but  that  the  lull  solution  could  be  implemented  if  there  was  time 
remaining  at  the  end  of  this  project.  There  was  no  extra  time  available  to 
implement  the  lull  solution. 

Scripting  in  display:  This  consisted  in  adding  the  ability  for  the  system 
developers  (currently  CAE  PS)  to  make  certain  parts  of  simDisplay  configurable 
via  a  configuration  file,  and  for  the  experiment  developers  to  make  the  Operator 
View  configurable  (the  Operator  View  represents  the  Operator  Console  of  the  real 
system,  i.e.  shows  sensor  displays,  a  moving  map  display,  and  thumbnail  selection 
bar). 

CAE  PS  added  a  Lua  inteipreter  to  simDisplay,  as  was  added  to  simControl  many 
phases  ago.  However,  contrary  to  simControl,  this  was  added  via  a  code  generation 
tool,  called  tolua++,  providing  a  much  more  object-oriented  interface  into  the 
application’s  properties  and  behaviour.  This  required  more  time  than  planned  as 
tolua++  had  never  been  used  before  in  the  system.  The  simDisplay  will  look  for 
the  configuration  script,  called  displayConfig.lua,  in  the  experiment’s  folder,  but 
uses  a  default  setup  identical  to  the  view  used  before  this  feature  was  added  if  the 
configuration  file  is  not  found. 

Exporting  new  functions  in  a  type-safe,  robust  and  object-oriented  manner  is  very 
straightforward  using  this  tool  and  will  support  future  extensions  to  simDisplay 
configurability.  It  is  so  powerful  in  fact  that  CAE  PS  recommends  replacing  the 
raw  Lua  API  calls  made  in  simControl  by  tolua++  generated  code,  which  will 
make  the  access  to  system  constants,  variables  and  functions  easier,  less  verbose, 
and  supportive  of  larger  experiments. 

Configuration  of  the  Operator  View  was  added  such  that  the  view  can  be  divided 
into  a  hierarchy  of  subdisplays  using  an  intuitive  and  simple  ratio  system, 
providing  a  large  degree  of  flexibility  in  the  view  configuration.  It  allows  the 
experimenter  to  decide  not  only  the  placement  and  size  of  the  MMD,  main  and 
auxiliary  sensor  display  ports,  but  also  which  sensors  will  be  available  to  the 
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operator.  The  Display  Selector  Bar  (see  next  item)  can  therefore  appear  almost 
anywhere  on  the  display. 

6.  Display  thumbnails:  This  consisted  in  adding  a  set  of  configurable,  mouse- 
selectable  sensor  display  thumbnails  in  the  Operator  View.  The  thumbnails  are 
placed  in  a  “bar”  called  the  Display  Selector  Bar,  which  orients  itself  vertically  or 
horizontally  based  on  the  aspect  ratio  given  to  the  bar  in  the  configuration  file:  if 
the  bar  is  wider  than  it  is  high,  a  horizontal  bar  is  created,  and  vice  versa  for  a 
vertical  bar.  The  five  sensor  displays  (see  next  item)  are  visible  in  the  bar  and  can 
be  selected  with  the  mouse.  EO-type  displays  are  shown  in  the  main  display  port, 
whereas  IR-type  displays  are  shown  in  the  auxiliary >  display  port. 

The  notion  of  main  and  auxiliary  display  ports  is  new  to  the  system  and  was 
necessary  to  allow  for  a  convenient  way  of  deciding  where  each  sensor  display 
should  be  viewed  when  selected.  It  was  arbitrarily  decided  that  EO-type  sensors 
appear  in  the  main  port,  whereas  IR-type  sensors  go  to  the  auxiliary  port. 

In  the  next  phase,  CAE  PS  recommends  that  the  notion  of  primary  versus 
secondary  sensors  be  revisited,  as  it  only  works  for  a  system  having  only  two 
sensors.  An  N-sensor  system,  N>2  as  is  now  simulated  in  AIMSsim,  could  support 
the  notion  of  one  master  versus  N-l  slave  sensors.  It  is  not  yet  clear  what  the 
differences  would  be  between  master  and  slave  sensors. 

7.  Add  display  types:  This  consisted  in  adding  three  new  display  types,  each 
specified  very  broadly  by  the  client  in  terms  of  EO/IR  capabilities,  zoom  type  and 
fields  of  view.  The  sensor  modelling  in  AIMSsim  was  generalized  to  support 
future  changes  or  additions  of  types  of  sensors. 

Currently  two  types  of  sensors  are  supported  by  the  system,  namely  “EO-type”  or 
“IR-type”.  The  former  maintains  the  de  facto  “EO”  misnomer  to  refer  to  sensors 
that  sense  radiation  in  the  visible  part  of  the  spectrum,  whereas  the  latter  are 
defined  as  sensors  that  sense  radiation  in  the  (non- visible)  inffa-red-and-beyond.  If 
sensors  are  ever  created  for  “above  visible”  light,  such  as  UV  and  beyond,  a  third 
category  could  easily  be  created  for  “UV-type”  sensors. 

All  sensors  share  a  common  set  of  capabilities.  IR-type  sensors  have  in  addition 
the  ability  to  change  polarity,  whereas  EO-type  sensors  have  in  addition  the  ability 
to  change  to  greyscale.  In  this  new  scheme  the  AGTV  sensor  from  the  previous 
version  of  AIMSsim  is  an  EO-type  sensor  with  active  gating  capability,  i.e.  a  laser 
illuminator,  while  the  FLIR  is  an  IR-type  sensor. 

As  per  the  client  specification  received  during  the  project,  two  new  EO-type 
sensors  were  added,  and  one  IR-type  sensor,  a  Thermal  Imager  (THIR).  All  types 
of  sensors  share  the  ability  to  have  different  types  of  zoom  and  fields  of  view, 
specifiable  in  the  experiment  scripts.  It  is  therefore  the  experimenter’s 
responsibility  to  assign  zoom  types  and  field  of  views  and  constrain  them  as  (and 
if)  necessary  during  the  experiment.  All  sensor  types  have  a  shader  file  that  defines 
how  their  image  is  rendered. 

8.  Dialog  customization:  This  consisted  in  adding  the  ability  for  the  experimenter  to 
define  new  dialog  screens  wherein  they  could  post  a  question  on  the  screen  to  the 
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operator,  and  capture  a  mouse  click  on  buttons  displayed  in  the  dialog.  The  system 
supports  the  addition  of  any  number  of  dialog  screens  containing  text  and  buttons, 
with  experimenter-specified  event  names  to  be  used  in  their  Finite-State  machine 
for  changing  the  course  of  the  experiment  or  saving  responses/data. 

9.  SGE  cleanup:  This  was  originally  included  in  the  SOW  to  allow  for  better 
coherence  between  the  scenario  generation  environment  (SGE)  and  the  simulation 
application  (AIMSsim).  This  weakened  coherence  was  a  result  of  a  major  rework 
done  to  the  system  prior  to  CAE  PS’s  involvement  in  its  porting  and  subsequent 
development.  This  made  it  difficult  to  ensure  that  values  saved  in  files  generated 
by  the  SGE  matched  the  values  expected  by  AIMSsim.  As  part  of  the  combination 
of  items  10  and  1 1  below  into  a  “next  generation”  SGE  (see  below),  this  work 
item  was  abandoned  and  its  hours  informally  transferred  to  other  tasks  on  an  as- 
needed  basis. 

10.  SGE  usability:  This  originally  consisted  of  improving  the  current  SGE  to  support 
the  new  capabilities  of  AIMSsim,  added  over  the  past  two  years.  Flowever, 
discussions  with  the  client  after  the  project  started  showed  that  the  SGE,  a  legacy 
application  almost  10  years  of  age,  had  become  impractical  to  update  and  that  it 
would  be  preferable  to  spend  the  effort  specifying  and  designing  a  “next 
generation  SGE”. 

This  new  GUI  would  support  the  creation  and  generation  of  scenarios  as  well  as 
the  management  and  monitoring  of  experiments  (described  in  work  item  1 1 , 
below),  making  use  of  the  current  simControl,  simlnputs  and  simDisplay 
components.  In  this  report  the  proposed  application  is  referred  to  as  the  AIMS 
Simulation  Experimentation  Station  (ASES)  as  it  will  support  all  aspects  of  the 
simulation-based  experimentation  of  AIMS  in  one  integrated  application. 

This  work  item  was  therefore  modified  to  include  the  specification,  design,  and  a 
preliminary  implementation  of  the  ASES  application,  limited  by  the  constraint  that 
the  total  project  money  could  not  be  changed.  The  preliminary  implementation  is 
therefore  at  a  rather  early  stage  but  demonstrates  the  integration  of  Python, 
OpenSceneGraph  and  wxAUI  as  effective  implementation  components  for  the 
system.  The  specification  and  design  are  described  in  the  appendix. 

11.  Manage  simulation:  This  originally  consisted  of  creating  a  GUI  to  simplify  the 
experimenter’s  task  of  starting  and  stopping  an  experiment  and  monitoring  the  log 
files  for  warnings  or  errors  (especially  during  start-up  and  experiment  transitions). 
As  described  in  item  1 0  above,  this  work  item  was  merged  into  the  modified  item 
10,  i.e.  the  specification  and  design  of  the  ASES  application,  described  in  the 
appendix. 

12.  Releases  and  Quality  Assurance  (QA):  This  consists  in  the  delivery  over  FTP  of 
“releases”  of  the  software  as  often  as  possible  so  the  client  can  test  and  provide 
feedback.  Several  releases  were  made  available  to  the  client.  Some  unplanned 
effort  was  spent  on  the  transport  of  the  release  over  FTP  since  the  FTP  server  used 
in  the  previous  phase  was  no  longer  available  and  the  new  one  could  not  be  used, 
presumably  due  to  firewall  restrictions  on  both  the  CAE  PS  and  client  sides. 


6 


DRDC  Atlantic  CR  2007-302 


DRDC  IT  explicitly  changed  their  firewall  to  allow  CAE  PS  to  upload  files  to  their 
FTP  site.  The  client  was  able  to  test  each  release  and  provide  feedback  or 
requirements  for  fixes. 

13.  Final  deliverables:  This  consists  of  all  the  closure-related  activities  of  the  project, 
such  as  producing  the  CD  with  the  deliverables  and  shipping,  writing  the  final 
report,  creating  closure  documents  such  as  feedback  forms,  etc. 

14.  Script  support:  This  was  an  unspecified  task  in  the  event  that  the  client  may  need 
support  in  writing  scripts  for  their  new  experiments  or  to  test  new  features  of  the 
system. 

15.  Update  manuals:  This  consisted  in  updating  the  System  and  User  manuals  to 
cover  the  new  features  and  capabilities  of  the  system.  A  significant  amount  of 
documentation  was  added,  in  some  cases  covering  features  that  had  been  added  in 
the  previous  phases  but  had  been  only  partially  documented. 

16.  Additional  effort  as  required:  This  was  an  unspecified  task  which  was  not 
required. 

17.  Setup  and  development  environment:  This  consisted  of  installing  upgraded 
versions  of  several  third-party  libraries  used  in  the  building  of  AIMSsim.  FLTK, 
boost,  and  several  others  were  upgraded. 

The  upgrade  to  OpenSceneGraph  (OSG)  1.2  was  started  but  interrupted  due  to  a 
critical  bug  in  that  version  of  the  library  that  prevented  the  use  of  shaders  (used  for 
all  sensor  displays  to  model  grey  scaling,  noise,  fog,  laser  illumination,  etc)  in  the 
AIMSsim  sensor  displays. 

An  upgrade  to  OSG  2.0  was  successful  just  before  the  end  of  the  project:  no 
changes  to  the  code  were  necessary  to  build  and  run  AIMSsim  using  the  OSG  2.0 
distribution.  However,  there  wasn’t  sufficient  time  to  fully  test  the  system  to 
minimize  the  chance  of  broken  features,  hence  the  AIMSsim  delivered  to  the  client 
is  still  using  OSG  1.0. 

Over  the  past  8  months  the  OSG  library  has  progressed  to  version  2.2,  so  another 
attempt  to  upgrade  should  be  repeated  in  the  next  phase.  The  upgrade  itself  should 
be  painless,  however  some  time  should  be  set  aside  for  proper  testing,  and  for 
replacing  some  of  the  code  (if  any)  that  uses  deprecated  OSG  classes. 
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4.  Future  Work  Recommendations 


For  the  next  phase,  CAE  PS  recommends  the  following  work  items.  These 
recommendations  should  be  taken  into  consideration  in  light  of  any  other  client 
requirements. 

Operator-Machine  Interface  (OMI): 

1.  Complete  a  prototype  for  ASES.  This  could  involve  item  6  below,  as  well  as 
allowing  the  simControl  and  simDisplay  to  be  “reset”  without  having  to  restart  or 
reload  the  terrain  (the  most  time-consuming  aspect  of  start-up  and  resets). 

2.  Test  with  more  USB  joysticks:  test  and  fix  as  required  to  support  a  specified  set  of 
USB  joysticks. 

3.  Add  sensor  history  to  MMD:  add  the  history  of  sensor  coverage  to  MMD.  This 
requires  defining  how  sensor  coverage  is  measured: 

a.  Which  of  the  five  sensors  should  be  used,  as  they  each  have  independent  fields 
of  view  (possibilities  are  numerous,  e.g.  average  of  all  FOVs,  or  a  $300  head¬ 
tracking  device  by  NaturalPoint); 

b.  Is  shadowing  taken  into  account:  uneven  terrain  limits  the  actual  terrain  seen 
in  sensor  displays,  such  that  straightforward  sensor  FOV  projection  grossly 
overestimates  how  much  ground  was  covered; 

c.  Is  horizontal  distance  from  aircraft  taken  into  account:  visibility  distance,  and 
pixel  coverage  ratio  can  severely  limit  how  much  is  visible  in  the  display  and 
grossly  overestimate  how  much  ground  was  covered; 

d.  how  often  it  should  be  recorded  (every  second,  30  times  per  second  etc); 

e.  how  long  is  the  history  kept  for,  e.g.  10  frames,  2  minutes,  the  whole 
experiment  duration;  impacts  the  memory,  data  storage  and  rendering 
performance  characteristics. 

4.  Upgrade  simDisplay  to  most  recent  stable  version  of  OpenSceneGraph  and  replace 
old  code  that  depends  on  Producer  with  new  osgViewer-based  code. 

5.  Add  the  ability  to  configure  the  sensor  overlay  text  from  display  configuration 
script. 

6.  Add  the  ability  to  turn  on  some  features  which  are  currently  available  only  to 
developers  in  debug  builds  (such  as  designation  boxes,  target  placement  beams, 
non-root  window). 
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Scripting: 

7.  Add  world  hierarchy:  split  the  terrain  database  and  add  capabilities  to  attach 
geometry  to  terrain  so  that  canopy  would  be  in  a  separate  file  that  would  be 
included  by  experimenter  only  in  relevant  experiments. 

8.  Revise  notion  of  Primary  versus  Secondary  displays. 

9.  Upgrade  Lua  scripting  in  simControl :  upgrade  Lua  scripting  engine  in  simControl 
to  use  tolua++  and  provide  a  more  powerful  extension  mechanism  and  experiment 
definition  framework. 

10.  Facilitate  copying  of  experiments:  copying  an  experiment  should  not  require  the 
search  of  scripts  for  path  names,  which  makes  re-use  of  experiments  very  prone  to 
errors. 

11.  Event-triggered  Lua  code:  allow  Lua  code  to  be  called  in  response  to  an  event; 
currently  a  script  must  be  run,  which  can  cause  a  multitude  of  small  scripts  to  be 
created  and  makes  the  experiment  creation  more  difficult  (may  become  a  non¬ 
issue  with  ASES). 

Documentation: 

12.  Rewrite  documentation  for  online  access. 

13.  Rewrite  documentation  to  change  presentation  of  system  via  ASES  rather  than  via 
backend  components  ( simControl  etc). 
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Annex  A:  Specification  and  Design  of  ASES 

This  appendix  gives  a  preliminary  specification  and  design  for  the  AIMS  Simulation- 
based  Experimentation  Station  (ASES)  application. 

The  development  of  ASES  is  motivated  by  the  fact  that  the  current  Scenario  Generation 
Environment  (SGE)  is  based  on  old  technology  and  has  fallen  far  behind  in  its 
capabilities  relative  to  AIMSsim,  and  updating  it  would  be  more  costly  than  starting 
from  scratch.  Moreover,  the  SGE  is  merely  a  generation  environment,  whereas  the  client 
has  expressed  a  need  for  a  testing  and  control  environment. 

The  concept  of  operation  formed  through  discussions  and  interactions  with  the  client  is 
the  following: 

ASES  should  make  it  easy  for  a  novice  user  to  create  a  flight  plan,  add  some  targets, 
assign  path  plans  to  them,  and  run  the  scenario,  all  from  the  GUI. 

CAE  PS  recommends  that  ASES  divide  the  above  into  three  “task  areas”  available  from 
one  GUI: 

1 .  Create  a  scenario:  this  task  area  is  where  the  user  is  provided  with  tools  to  create 
paths  and  targets,  define  events  and  transitions  between  stages  of  the  scenario,  set 
attributes  of  the  entities  available,  and  facilitate  the  use  of  the  exported  AIMSsim 
functions  available  in  the  scenario  scripts;  ASES  must  do  so  in  such  a  way  that  the 
user  can  decide  at  which  stage  of  a  scenario  each  of  the  above  changes  must  take 
place. 

2.  Test  the  scenario,  in  preparation  for  experiment:  this  task  area  is  where  the  user 
can  run  the  experiment  and  get  extra  information  that  will  help  troubleshoot  the 
scenario  behaviour,  e.  g.  the  list  of  timed  events  queued,  the  list  of  periodic  scripts 
currently  active,  etc,  all  items  that  are  difficult  (or  not  currently  possible)  to  get 
from  the  scenario  scripts  but  are  crucial  in  helping  determine  why  some  data  is  not 
being  saved  or  why  the  scenario  is  not  transitioning  to  an  expected  stage.  In 
addition,  being  able  to  see  the  log  files  and  filter  them  would  be  useful.  The 
AIMSsim  would  probably  run  as  a  non-root  decorated  window  beside  the  ASES 
GUI. 

3.  Run  the  scenario  for  real  experiment:  this  task  area  is  where  the  user  can  run  the 
experiment  and  see  filtered  views  of  the  log  files  but  not  the  other  test  tools.  The 
AIMSsim  would  probably  run  on  root  window  in  front  of  the  ASES  GUI. 

Eventhough  tasks  2  and  3  share  some  graphical  elements  and  capabilities,  there  are 
also  significant  differences  that  indicate  they  should  be  kept  logically  separate  at  the 
architectural  level. 
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Scenario  Creation 

A  scenario  consists  of  a  set  of  stages  and  transitions  between  some  of  them,  and  only 
one  “INIT”  stage  and  one  “EXIT”  stage  (previously  known  as  finite  states).  Scenario 
creation  can  involve  any  or  all  of  the  following  activities: 

Create/define: 

1.  Path  plans:  define  sequences  of  waypoints,  speeds,  accelerations,  radius  of  turn; 
define  paths  from  joining  smaller  paths;  no  limit  on  number  of  plans  allowed; 

2.  Targets:  define  placement  (i.e.  position  and  orientiation)  and  geometry;  number  of 
targets  allowed  may  be  limited  but  high; 

3.  User  event  names 

4.  Scenario  stage  names 

5.  Tasks  (previously  known  as  periodic  scripts) 

6.  Dialog  screens 

7.  Operator  View  configuration 

8.  Global  variables 

9.  Variables  local  to  a  scenario  stage 

10.  Log  files 

11.  Datafiles 

Change  attributes  of: 

1 .  Created  targets,  such  as  which  sensor  display  a  target  is  visible  in,  what  is  the 
target’s  label,  x,  y,  z  position,  etc 

2.  Sensor  displays 

3.  Moving  map  display  (MMD) 

4.  Other  system  attributes  (participant  number,  etc.) 

Incorporate  commands  in  a  scenario  stage: 

1.  Action  commands  (send  message  to  display,  timed  events,  etc.) 

2.  Query  commands  (e.g.  get  sensor  orientation) 

3.  Other  commands  (e.g.  set  sensor  orientation) 

It  is  not  possible  to  know  at  what  scenario  stage  the  user  will  want  a  given  “thing” 
(object,  attribute,  command,  etc.)  to  be  created  or  used.  It  would  also  be  useful  to 
allow  the  user  to  make  use  of  system-defined  names  in  their  scenarios.  The  following 
strategy  can  be  used  to  facilitate  this: 

1 .  An  “Entities”  panel  shows  all  the  above  “things”  that  can  be  created  or  defined, 
plus  all  the  system  entities.  The  latter  cannot  be  deleted  or  renamed. 

2.  This  “Entities”  panel  also  shows  all  the  attributes  for  the  given  entities.  Each  entity 
has  a  “preview”  panel  that  can  be  made  visible.  The  attributes  can  be  changed  in 
the  tree,  and  the  corresponding  “preview”  panel  shows  how  this  would  affect  the 
entity. 

3.  The  user  can  drag  entities  and  entity  attributes  from  the  “Entities”  panel  onto  a 
“Stage  Definition”  panel,  thereby  creating  an  entry  in  their  scenario  stage  for 
setting  that  attribute.  Further  changing  the  attributes  in  the  tree  does  not  affect  the 
scenario  stage  command  just  created. 


12 


DRDC  Atlantic  CR  2007-302 


The  default  “Entities”  view  would  start  as  the  following  tree: 


Global  variables 
OMI 

Dialog  screens 
Operator  View 
ROOT 
MMD 

Up  orientation  (North,  Aircraft,  Camera) 

AGTV  sensor  footprint  visibility 
Sensor  displays 
AGTV 

Color 

Laser  illuminator  on/off 
FLIR 

White  is  hot 


World 

Terrain 

File 

Aircraft 

Position  (x,y) 

Camera  orientation  (hpr) 

Bearing 
Targets 
Path  plans 
Events 

START_PRESSED 
0  PE  RAT I ONAL_U  PDAT E  D 

BUTTON_TLL 

BUTTON_TCL 

BUTTON_BRR 

Stages 

INIT  (init) 

EXIT  (exit) 

Tasks 
Log  files 
External  scripts 
Commands 

SendMessage 

SetLogLevel 


A  variety  of  actions  would  be  possible  on  the  above  entities: 

1 .  Left-click:  select  the  entity;  this  would  probably  only  make  sense  on  entities 
that  have  attributes,  such  as  sensor  display  entities  (AGTV  etc),  MMD, 
targets,  etc  or  on  entities  that  can  be  dragged  onto  the  editing  areas  (see  below) 
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2.  Right-click:  show  a  pull-down  context  menu  with  available  operations  on  the 
entity.  E.g.  right-clicking  on  ‘Targets’  node  would  show  ‘Create  new  target’, 
amongst  others.  Right-clicking  on  a  target  would  show  ‘Delete  target’.  Not  all 
entities  support  operations.  E.g.  what  can  be  done  to  a  sensor  display? 

3.  Left-click  drag:  dragging  something  from  the  tree  onto  another  panel  of  the 
GUI,  such  as  the  “Stage  Definition”  panel;  this  would  be  the  mechanism  of 
choice  to  define  scenario  stages. 


The  entities  window  maintains  a  “state”,  i.e.  shows  the  current  value(s)  of  all  attributes 
in  editable  text  boxes  in  the  window.  This  state  can  be  reset  without  affecting  the 
scenario  stages,  as  it  is  merely  for  “previewing”  to  help  the  User  decide  what  to  put  in 
the  scenario  stages.  E.g.  after  selecting  a  terrain  the  Entities  window  might  show 


World 

—  Terrain 
I —  File 


C:\AIMS_DB\terrains\nerepis\... 


And  the  World  preview  pane  would  show  the  terrain. 

A  full  specification  of  ASES  would  take  all  attributes  and  commands  detailed  in  the 

User  manual  and  define  where  in  the  Entities  window  they  would  appear. 

The  following  explains  some  use  cases: 

1 .  Define  terrain 

a.  Select  “World->Terrain->File”  node’s  browse  button;  ASES  shows  file 
browser; 

b.  Select  terrain  from  file  browser; 

c.  OK  accepts  the  selection  and  loads  the  terrain;  cancel  abandons  the 
selection  of  a  terrain,  leaving  the  previous  selection,  if  any,  loaded; 

d.  Once  you  see  the  terrain  loaded  and  you  are  satisfied  that  this  should  be 
used  in  scenario,  drag  the  node  onto  the  scenario  stage  in  which  it  should 
be  defined,  e.g.  the  INIT  stage’s  node;  alternately,  you  can  right-click  the 
File  node  and  select  “send  to  stage”  and  “INIT”; 

e.  ASES  shows  the  INIT  node’s  EZedit  panel  with  the  new  command  for 
terrain. 
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2.  Create  target: 

a.  Right-click  on  Targets  in  Entities  panel  and  select  “Create  new  target”; 
this  is  only  available  if  a  terrain  has  been  defined; 

b.  ASES  shows  the  World  preview  panel  and  changes  cursor  shape  when 
mouse  over  World,  indicating  a  target  is  about  to  be  “placed”; 

c.  Scroll  World  view  until  satisfied;  click  on  map  where  target  should  be 
positioned; 

d.  ASES  adds  a  node  as  child  of  Targets  with  new  Target  entity  and  makes 
visible  its  attributes,  such  as  name,  label,  position,  etc; 

e.  You  can  make  changes  to  any  of  the  attributes  and  the  changes  get 
immediately  reflected  in  World  view; 

f.  Once  satisfied  with  the  settings,  you  drag  the  Target  node  to  the  stage 
where  it  should  be  created  (or,  right-click,  Send  to  stage,  select  the  stage); 
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g.  Drag  the  new  target’s  attribute  nodes  to  the  appropriate  scenario  stage(s); 
multiple  selections  are  allowed  at  once; 

h.  You  can  edit  the  Target’s  attribute  nodes  in  the  Entities  panel,  this  updates 
the  World  view  but  not  the  entries  added  to  the  scenario  stages;  or  you  can 
move  the  target  in  the  World  view,  this  updates  the  target’s  position 
attribute  in  the  Entities  window,  but  doesn’t  affect  the  scenario  stage  data; 
drag  the  new  values  to  the  desired  scenario  stage  to  make  use  of  new 
values  in  scenario;  ASES  should  mark  edited  attributes  that  have  not  been 
“sent  to”  a  scenario  stage  to  help  you  remember  what  you  have  edited  but 
not  yet  “committed”  to  the  scenario; 

i.  You  can  edit  the  Target’s  attributes  in  the  EZedit  window,  this  does  not 
affect  the  values  in  the  Entities  window;  for  that,  right  click  on  the  EZedit 
entry  and  select  “send  to  preview”; 

3.  Change  target  visibility  in  the  AGTV  sensor  display 

a.  Bring  up  the  preview  for  the  AGTV  sensor  display;  this  will  only  be 
possible  if  a  terrain  has  been  loaded; 

b.  Verify  on  the  World  view  that  the  aircraft  is  at  a  convenient  location:  drag 
the  aircraft  to  a  good  position,  not  too  far  from  the  target; 

c.  Use  the  FlyPanel  controls  to  move  the  camera  to  bring  the  target  into 
view; 

d.  In  the  target’s  attributes  area  of  the  Entities  window,  change  its  visibility 
attribute  (e.g.,  color,  etc);  observe  the  effect  in  the  AGTV  preview; 

e.  When  satisfied,  drag  the  attribute  to  the  desired  scenario  stage  where  the 
attribute  should  be  set; 

f.  If  you  want  the  aircraft  to  go  back  to  where  it  was,  find  the  stage  in  which 
the  aircraft  position  is  set,  and  do  “send  to  preview”; 

g.  Hide  any  windows  you  don’t  need. 

4.  Find  in  what  stages  an  attribute  is  changed 

a.  Right-click  on  the  attribute  in  the  Entities  window  and  select  “find  where 
changed”; 

b.  ASES  brings  up  the  EZedit  window  for  the  first  stage  that  it  finds  the 
attribute  gets  changed; 

c.  Repeat  to  find  the  next  occurrence. 

5.  Create  a  path  plan 
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a.  Right-click  the  Path  Plans  node  in  Entities  window  and  select  “Create  new 
simple”; 

b.  ASES  shows  the  World  view  and  the  cursor  changes  shape  to  indicate  that 
the  next  click  on  the  World  will  position  the  path’s  first  waypoint; 

c.  Click  on  the  view  to  position  first  waypoint;  ASES  shows  a  waypoint  and 
a  line  that  joins  the  new  waypoint  to  the  mouse  cursor,  indicating  that  the 
next  click  on  map  will  position  next  waypoint  and  line  is  the  path  segment 
between  the  two  waypoints; 

d.  As  the  path  is  created,  ASES  updates  the  “Path  profile”  preview,  which 
gives  a  visual  representation  of  the  attributes  of  the  sequence  of 
waypoints; 


e.  Drag  the  node  for  the  path  plan  from  Entities  window  and  drop  it  onto  the 
stage  where  the  path  plan  should  get  created. 

6.  Create  a  composite  path  plan 

a.  Right-click  the  Path  Plans  node  in  Entities  window  and  select  “Create  new 
composite”; 

b.  ASES  adds  a  node  in  the  Entity  window; 

c.  Drag  other  plans  onto  the  new  node  to  create  the  sequence  of  plans  to 
follow. 

7.  Assign  a  path  plan  to  a  target  and/or  aircraft 

a.  Create  a  path  plan; 
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b.  Drag  the  path  plan’s  node  (in  Entities  window)  onto  the  target(s)  and/or 
aircraft  nodes  (also  in  Entities  window)  to  make  those  vehicles  follow  the 
plan;  ASES  shows  the  total  plan  assigned  so  far  in  the  World  view; 

c.  Verify  on  the  world  view  that  this  really  is  what  you  want,  make  any 
adjustments  to  the  plan  object  (e.g.  by  moving  waypoints  on  the  World 
view) ; 

d.  Drag  the  “Path  plan  to  follow”  attribute  of  the  target  into  the  scenario 
stage  where  the  target  should  be  given  the  plan; 

e.  Determine  at  what  stage  the  target  should  actually  follow  the  path  plan; 

f.  Drag  the  “Resume  motion”  command  from  target  node  on  the  stage  when 
target  should  start  moving  along  path. 

8.  Create  a  new  scenario  stage 

a.  Right-click  on  Stages  in  Entities  panel  and  select  “Create  new  stage”; 

b.  ASES  creates  a  new  entry  in  the  tree  and  allows  you  to  name  it;  the  name 
must  be  different  from  an  existing  one; 

c.  If  desired,  select  new  stage  in  tree  to  bring  up  its  EZedit  window,  and  edit 
using  the  window’s  tools;  alternately,  drag  nodes  from  the  Entities 
window  onto  the  EZedit  window  of  the  stage  to  copy  them  over  into  the 
scenario. 


9.  Define  a  new  transition  between  two  stages 

a.  Right-click  the  node  of  the  “from”  stage  in  Entities  panel  and  select  “Add 
transition”;  this  adds  an  entry  with  a  “to”  box,  and  an  “event”  box; 

b.  Drag  one  of  the  other  stages  onto  the  “to”  box  to  fill  it  with  that  stage’s 
name; 
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c.  Drag  one  of  the  Event  nodes  onto  the  “event”  box  to  fill  it  with  that 
stage’s  name; 

d.  If  available,  the  Stages  preview  panel  should  show  the  updated  stage- 
transition  diagram. 


Scenario  Testing 

Scenario  testing  can  start  if  the  scenario  scripts  have  been  generated  since  the  last 
scenario  project  save.  The  GUI  should  hide  all  the  scenario  creation  panels  and  show  the 
scenario  testing  panels.  Two  monitors  will  be  recommended:  one  for  ASES,  one  for 
AIMSsim. 

The  following  activities  are  typical  of  testing  a  scenario  being  created: 

1.  Start  the  simulation  system  for  the  currently  loaded  scenario;  starting  it  causes 
simulation  processes  to  be  started  in  right  order,  from  correct  folder;  user  can 
select  to  not  start  some  of  the  default  processes  that  would  otherwise  get  started; 
user  can  enter  extra  parameters 

2.  Stop  the  simulation  system,  causing  graceful  exit;  user  can  choose  which 
processes  to  stop  if  desired; 


3.  View  logs  created:  one  tab  per  log,  showing  one  column  for  time,  one  for  log  id, 
one  for  message;  and  updated  in  real  time;  each  log  view  allows  a  filter  on  that 
log;  the  filter  can  be  copied  to  other  log  views;  new  log  tabs  are  generated  if 
scripts  create  new  logs; 

4.  View  the  time  information  for  system:  time  since  start  of  system  (run  —  ie  clock  — 
time),  cumulative  simulation  time  (which  advances  only  if  at  least  one  vehicle  is 
moving),  flight  time;  view  the  state  snapshot  which  is  the  subset  of  Entities  tree 
window  of  Scenario  Creation  GUI,  showing  current  values  of  attributes. 
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5.  View  timed  events  queue:  this  shows  when  (simulation  time)  the  events  will  be 
triggered,  and  what  script  will  be  run; 

6.  View  tasks  (periodic  scripts); 

7.  View  stages:  shows  history  of  scenario  stages  executed  so  far,  the  transitions  that 
caused  them  to  execute;  time  of  transitions; 

8.  View  World  (read-only  mode);  when  user  selects  something  in  view,  its  current 
state,  as  per  simulation,  is  shown  in  a  separate  panel.  This  is  useful  since  it  may 
happen  that  the  MMD  in  the  simulation  has  been  turned  off  or  may  not  contain  all 
information  necessary  for  testing. 


Scenario  Running 

For  running  a  scenario,  most  of  the  testing  panels  are  not  required.  In  addition,  the 
simDisplay  should  occupy  the  whole  root  window  atop  the  ASES  window  so  that  the 
operator  cannot  tamper  with  the  settings.  If  this  is  not  practical,  the  ASES  GUI  could  be 
“locked”  after  a  run  is  started,  requiring  a  password  to  be  unlocked.  In  this  way  the  logs 
would  still  be  visible.  The  first  three  items  from  the  Scenario  Testing  activities  should  be 
available. 


Main  frame 

The  GUI  main  frame  is  the  “whole  application”  GUI,  i.e.  the  main  window  of  the 
application  with  the  menus,  toolbar(s),  status  bar  and  central  (“client”)  area  where  the 
panels  change  based  on  the  task  at  hand. 

The  main  frame  should  support  docking  and  undocking  of  any  panel  created  such  that 
the  user  can  decide  where  they  want  to  position  panels.  This  configuration  should  be 
saveable  so  that  next  time  the  application  is  run  the  default  views  will  be  the  same. 

The  menu  bar  should  have  at  least  the  following  items,  before  a  scenario  is  loaded  or  a 
new  one  started: 

File 
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New,  Open,  Save,  Save  As... 

Generate  scripts 
Print 
Exit 
View 

Show  panel... 

Task 

Create 

Test 

Run 

Tools 

Options 

Help 

Manual 

About 

As  soon  as  a  scenario  has  been  loaded  a  new  one  created,  the  above  menu  will  contain 
extra  items  based  on  the  chosen  task  (create,  test,  run). 
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List  of  abbreviations  and  acronyms 


AGTV 

Active-Gated  TV 

AIMS 

Advanced  Integrated  Multi-Sensor  system 

API 

Application  Programming  Interface 

ASES 

AIMS  Simulation-based  Experimentation  Station  (ASES) 

CAE  PS 

CAE  Professional  Services 

DLL 

Dynamically  Loaded  Library 

DND 

Department  of  National  Defence 

EO 

Electro-Optical 

FUR 

Forward-Looking  IR 

FOV 

Field-of-View 

FTP 

File  Transfer  Protocol 

GUI 

Graphical  User  Interface 

HMI 

Human-Machine  Interaction 

IR 

Infra-Red 

IT 

Information  Technologies 

MMD 

Moving  Map  Display 

OMI 

Operator-Machine  Interface 

POV 

Point-of-View 

PDF 

Portable  Document  Format 

QA 

Quality  Assurance 

SAR 

Search-and-Rescue 

SGE 

Scenario  Generation  Environment 

SOW 

Statement  of  Work 

THIR 

Thermal  Imager 

uv 

Ultra-Violet 
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de  recherche  sert  a  evaluer  les  principes  de  conception  et  le  rendement  de  I’operateur  et  est  derivee  du 
systeme  AIMS  (anciennement  appele  Systeme  perfectionne  de  surveillance  a  intensification  de  lumiere  visible 
et  a  infrarouge  ou  ELVISS)  qui  est  en  cours  de  developpement  a  RDDC  Valcartier.  Equipe  de  deux  a  cinq 
capteurs,  le  systeme  AIMS  ameliorera  la  capacite  de  recherche  et  sauvetage  (SAR)  en  permettant  aux 
equipages  de  travailler  avec  efficacite  la  nuit  et  par  intemperie.  Le  rapport  resume  le  travail  effectue  dans  le 
cadre  du  projet  et  fait  des  recommandations  pour  la  prochaine  phase.  Les  taches  de  base  comprenaient  I’ajout 
de  fonctions  pour  surpasser  le  controleur  des  capteurs  par  defaut  sur  le  boTtier  de  commande  et  le  remplacer 
par  un  controleur  a  bus  serie  universel  (USB)  et  I’ajout  de  la  capacite  a  reamenager  les  fenetres  de  capteur  et 
d’autres  caracteristiques  sur  I’affichage  d'interface  et  d'autres  zones  de  I'interface.  Les  deux  capacites  ont  ete 
ajoutees  dans  le  but  d’evaluer  des  outils  et  les  principes  de  conception  de  I’interface. 

14.  KEYWORDS,  DESCRIPTORS  or  IDENTIFIERS  (Technically  meaningful  terms  or  short  phrases  that  characterize  a  document  and  could  be  helpful  in  cataloguing  the 
document.  They  should  be  selected  so  that  no  security  classification  is  required.  Identifiers,  such  as  equipment  model  designation,  trade  name,  military  project  code 
name,  geographic  location  may  also  be  included.  If  possible  keywords  should  be  selected  from  a  published  thesaurus,  e.g.  Thesaurus  of  Engineering  and  Scientific 
Terms  (TEST)  and  that  thesaurus  identified.  If  it  is  not  possible  to  select  indexing  terms  which  are  Unclassified,  the  classification  of  each  should  be  indicated  as  with 
the  title.) 

(U)  simulation,  airborne,  interface,  search  and  rescue,  surveillance 
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